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(54) Prioritized load balancing among non-communicating processes in a time-sharing system 



(57) A method and apparatus for prioritized load- 
balancing among non-communicating processes in a 
time-sharing system involves a Load Balancing Repos- 
itory (LBR) which interfaces with each process that is 
actively addressed by the CPU. A scheduler within each 
process provides the LBR with a load distribution for that 
process representing the ratio of high-priority sub-task 
load to low-priority sub-task load. The LBR determines 
a target ratio in the form of an aggregate load distribution 



ratio. The largot ratio is reported back to each active 
process. For processes which are occupied with a rela- 
tively low proportion of high priority sub-tasks and which 
therefore exhibit a load distribution that is below the tar- 
get ratio, the process scheduler will give up a portion of 
the time slice allotted to that process by the operating 
system when the load distribution of that process reach- 
es the target ratio. Thus, CPU resources will be applied 
more frequently to processes which are occupied with 
a relatively high proportion of high priority sub-tasks. 
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Description 

Background Of The Invention 

[0001] This invention relates generally to methods 
and apparatus for controlling digital processing systems 
involving at least one central processing unit (CPU) and 
a plurality of application processes to be performed. 
Specifically, the invention relates to systems and tech- 
niques for balancing or distributing CPU load among 
non -communicating processes in a time-sharing sys- 
tem. 

[0002] In time-sharing or multitasking environments, 
many application processes or tasks may, at a given 
time, compete for processing resources provided by one 
or more central processing units. While the CPU does 
not typically execute processes simultaneously, the 
processes are active in the sense that they share CPU 
resources, i.e., processing time, until they are complet- 
ed. 

[0003] The real-time occupancy of CPU resources by 
an active application processes is referred to as the 
CPU "load" attributable to that process. In a time-shar- 
ing system, the load attributable to each active applica- 
tion process is often controlled or balanced by the op- 
erating system according to a predetermined protocol. 
The term "toad balancing* refers to systems and tech- 
niques for allocating CPU resources among active ap- 
plication processes. Load balancing may accomplish 
different desired objectives. For example, the CPU load 
attributable to each application process may be gov- 
erned according to preassigned priority levels. Other 
load-balancing techniques seek quick execution times 
for the application processes. 

[0004] In complex time-sharing or multitasking sys- 
tems, hundreds of application processes , or tasks, may 
be in active competition for CPU resources at a given 
time. Each of these application processes may include 
hundreds or thousands of sub-tasks. In wireless cellular 
communication systems, for example, telephone net- 
work access is provided through radio communication 
between mobile subscriber radiotelephones and cell 
sites located within contiguous geographic areas. Each 
cell site is equipped with various hardware and software, 
including radio transceivers, antennas and control 
equipment to facilitate signal transmission between mo- 
bile subscribers and the cell sites. In advanced cellular 
systems, control of a significant portion of cellular net- 
works may be provided through a single CPU, the re- 
sources of which are shared among multiple radio con- 
trol systems (RCS's), each supporting multiple micro- 
cells and each relying on its own resident software sup- 
port applications. An operating system, for example a 
UNIX-based operating system, is provided with a sched- 
uler which is responsible for sharing CPU resources 
among the RCS's. Within each RCS, software applica- 
tions processes are provided to control various sub- 
tasks, such as call processing, translation, and auditing 



associated with that RCS. These sub-tasks have vary- 
ing levels of importance or priority Operating systems 
like UNIX provide for externally assigned priories for the 
application processes running under them. Typically, all 
5 software application processes of equal priority are al- 
lotted equal portions of CPU time by UNIX. 
[0005] The aforementioned prioritizing techniques for 
load -balancing may provide inadequate results when 
applied to time-sharing systems like those employed to 
io control complex wireless communication networks. In 
such systems, the particular type of functions being ad- 
dressed at the sub-task level should be considered for 
proper load-balancing. With known techniques, howev- 
er, this is not feasible. Typically, memory or processing 
'5 limitations prevent the operating system from tracking 
detailed information at the sub-task level. Rather. CPU 
resources are allotted only with regard to the priorities 
assigned at the application process level. Known sys- 
tems therefore provide no capability for monitoring de- 
20 termining which application processes are, at any given 
time, devoting most of their CPU resource allotment to 
high priority sub-tasks. Nor do they provide the capabil- 
ity to monitor or determine which application processes 
are devoting most of their CPU time slice to accomplish 
25 low priority sub-tasks. Thus, the completion of high pri- 
ority tasks in one active application process may be de- 
layed while CPU resources are committed to tower pri- 
ority tasks in another application process. 
[0006] The problem becomes more apparent when 
30 explained in the context of the wireless communication 
system example discussed above. Sub-tasks associat- 
ed wilh call processing or translation are obviously more 
important than sub-tasks associated with auditing, 
maintenance or "housekeeping" functions: a "bottle- 
rs neck" in call processing might result in delays to sub- 
scribers placing calls. Maintenance sub-tasks, on the 
other hand, are usually designed to fill "idle time" within 
the CPU time slice allotted to a given process. Call 
processing and translation are "message driven" proc- 
40 esses, that is, they are initiated by external events like 
subscribers placing calls and the CPU resources they 
require vary from time to time. From the operating sys- 
tem's perspective, all application processes at a given 
UNIX priority level are competing for equal slices of CPU 
*s time. The operating system provides no way of deter- 
mining when one RCS is utilizing all of its CPU resource 
allotment to address call processing, a high-priority 
function, while another RCS may be utilizing all of its 
CPU resources only to accomplish less-important audit- 
so ing or maintenance functions. Thus, CPU resources are 
not allocated in a manner that favors completion of high- 
priority functions over low-priority functions at the sub- 
task level. 

[0007] It would therefore be desirable to provide a 
55 method and apparatus for toad-balancing which allo- 
cates CPU resources in a manner that favors comple- 
tion of high-priority functions over low-priority functions 
at the sub-task level. Such a system would be capable 
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of distributing the CPU load In such a manner that active 
application processes which are utilizing their CPU re- 
source allotment to complete a relatively small propor- 
tion of high-priority sub-tasks will relinquish resources 
in favor ot one or more other active processes that are 
utilizing their CPU resource allotment to complete a rel- 
atively high proportion of high-priority sub-tasks. 

Summary Of The Invention 

[0008] The present invention provides a method and 
an apparatus for load balancing among non-communi- 
cating processes in a time-sharing system which meth- 
od and apparatus achieve the aforementioned objec- 
tives. In accordance with the invention, CPU resources 
are allocated in a manner that favors completion of high- 
priority sub-tasks over completion of low-priority sub- 
tasks within all active processes. Sub-tasks in each ap- 
plication process are assigned one of at least two priority 
levels. Each process is provided with a reporting sub- 
task which interfaces with a Load Balance Repository 
(LBR). The LBR may be another process provided un- 
der the operating system. The interface may be a mes- 
sage interface or may be accomplished through shared 
memory access among the processes. The reporting 
sub-task of each active application process reports the 
load distribution for that process to the LBR. The load 
distribution is quantified in a ratio of the CPU load, i.e., 
processing time, attributable to highest priority sub- 
tasks to the CPU load attributable to each lower level o! 
priority sub-tasks, for that process to the LBR. 
[0009] The LBR determines a target load distribution 
ratio by aggregating the load distribution ratios of all ac- 
tive processes and reports the aggregate load distribu- 
tion back to each active application process as a target 
ratio. A scheduler within each process monitors the cur- 
rent load distribution ratio of that process. Processes 
that have a bad distribution ratio which is lower than the 
target ratb are utilizing CPU resources for a relatively 
small proportion of high-priority sub-tasks compared to 
the average proportion among all active processes. The 
corresponding scheduler within such processes relin- 
quishes CPU resources when the current load distribu- 
tion equals or exceeds the target ratio, thus sacrificing 
a portion of the CPU time slice allotted to that process 
under the operating system. 

[001 0] The invention provides the advantage that the 
CPU load distribution will evolve to a state in which ac- 
tive application processes that expend CPU resources 
toward the completion of a relatively high proportion of 
lower priority sub-tasks receive a shorter duration of 
CPU time, while CPU resources are applied more fre- 
quently to one or more other active processes which are 
expending CPU resources towards the completion of a 
relatively high portion of higher priority sub -tasks. 
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Brief Do script Ion Ot The Drawings 

[0011] The invention may take physical form in certain 
parts and steps, a preferred embodiment of which will 
s be described in detail in this specification and illustrated 
in the accompanying drawings which form a part hereof, 
wherein: 

Figure 1 is a schematic showing the organization 
io of a computer platform and a prioritized load bal- 
ancing system according to a preferred embodi- 
ment of the present invention; 

Figure 2 is a flow chart illustrating the Load Balance 
is Repository (LBR) process according to a preferred 
embodiment of the present invention; 

Figure 3 is a flow chart illustrating a process sched- 
uler according to a preferred embodiment of the 
20 present invention. 

Figure 4 A is a table representing the process load 
distributions at an initial LBR reporting interval ac- 
cording to the present invention; 

2S 

Figure 4B is a table representing the CPU load dis- 
tribution at a second LBR reporting interval accord- 
ing to the present invention; 

30 Figure 4C is a table representing the CPU load dis- 
tribution at a third LBR reporting interval according 
to the present invention; and 

Figure 4D is a table representing the CPU load dis- 
35 tribution at a fourth LBR reporting interval according 
to the present invention. 

Detailed Description Of The Preferred Embodiment 

40 [0012] Figure 1 is a schematic representation of a 
load-balancing system 100 according to the present in- 
vention. Computer platform 110 includes hardware com- 
ponents such as CPU 112 for executing instructions 
stored in RAM 114 and ROM 116. CPU 112 represents 
45 either single CPU or multiple CPU's operating in paral- 
lel. Those of ordinary skill will recognize that Figure 1 is 
a rather abbreviated depiction of computer platform 1 1 0, 
which would also typically include various peripheral de- 
vices and data buses. Only those elements ot platform 
so 110 necessary for a detailed description of the present 
invention are included. Computer platform 110 also in- 
cludes operating system 118 which provides a proce- 
dural interface between CPU 112 and a number (n) of 
application processes 122. Operating system 118 may 
55 be a full-function operating system such as UNIX. 
[0013] As exemplified by the schematic representa- 
tion of application process 1 , each application process 
122 includes a number (m) of sub-tasks which are exe- 
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cuted according to the administrative control of a corre- 
sponding scheduler 126 While only three application 
processes are represented in Figure 1 , it will be recog- 
nized that systems typical of those to which the invention 
is applicable may involve hundreds ot active application 
processes. In turn, each process may include hundreds 
or thousands of sub-tasks. 

[0014] The sub-tasks within each process 122 will 
have varying priority levels depending on their associ- 
ated function. The scheduler 126 within each process 
122 will always schedule higher priority sub-tasks to run 
before lower priority sub-tasks. In its simplest form, the 
scheduler 126 will recognize only two priority levels - 
high or low. In a more complex form, one o! several dif- 
ferent priority levels may be assigned to each sub-task. 
The present invention finds application to both priority 
schemes. 

[001 5] In accordance with the present invention, LBR 
120 interfaces with a reporting sub-task 124 in each of 
processes (1 -n). This interface may be in the form of a 
message interface implemented via operating system 
118. Alternatively, the interface may be implemented via 
shared memory access whereby each application proc- 
ess 1 22 is provided with routines (not illustrated) for writ- 
ing to and reading predetermined memory locations that 
a re also accessed by LBR 120. In the case of a message 
interface, the LBR will function to update the average 
for the reporting processes and the aggregate load for 
the CPU at the time that the message is received. The 
LBR could also f unction to update only at timed intervals 
for all processes. This would require the LBR reporting 
interval, described below, to be more frequent than the 
reporting interval of any application process 122. 
[001 6] Figure 2 is a flow chart depicting a process for 
implementing the LBR 120 according to the present in- 
vention. The flow chart describes the general logic flow 
for a system which has (n) processes and (j) priority lev- 
els of sub-tasks. At step 200, LBR 1 20 obtains the CPU 
load distribution from each active application process 
122. For each of the (n) active processes, the load dis- 
tribution is reported to LBR 120 by the application proc- 
ess scheduler 126 via reporting sub-task 124. The load 
attributable to sub -tasks of process (i) at a given priority 
level (j) may be represented by L(i,j). For example, L 
(1,1) represents the toad attributable to priority level 1 
(the highest priority level) sub-tasks in process 1; L1.2 
represents the toad attributable to priority level 2 sub- 
tasks in process 1 ; and L(2,1 ) represents the toad attrib- 
utable to priority level 1 sub-tasks in process 2. CPU 
load L may be represented by a value corresponding to 
the time, i.e. milliseconds, that the CPU is executing 
sub-tasks at a given priority level. 
[0017] Typically, operating system 118 will recognize 
different several different priority levels assigned to ap- 
plication processes (1-n). Application processes run- 
ning at identical priority levels are allotted equal 
amounts ot CPU time under operating system lie. The 
number of priority levels utilized by operating system 



118 may differ from the number of priority levels by the 
present invention. For example, UNIX-based operating 
systems may recognize eight (8) priority levels: 0 
through 7. Sub-tasks running under UNIX may be as- 

s signed one of eight priority levels. However, the load dis- 
tribution scheme of the present invention may recognize 
less than all of the UNIX priority levels. In such a case, 
each application would need to map the UNIX priority 
levels to the priority levels utilized by the LBR. For in- 

'0 stance, if the LBR implements a load distribution report- 
ing scheme that involves only two priority levels ~ high 
and low -- UNIX priority levels 0-3 would map to low pri- 
ority while UNIX priority levels 4-7 would map to high 
priority. This scheme permits application processes with 

*s different UNIX priority levels to compare loads on equiv- 
alent terms within the LBR implementation. 
[0018] Step 210 is a decision step where the LBR 
process evaluates whether the reporting interval has ex- 
pired. According to a preferred embodiment of the in- 

20 vention, the LBR periodically obtains the load distribu- 
tion ratios from each active process (I) according to a 
reporting interval, preferably on the order of one second, 
if the reporting interval has not expired, the LBR process 
returns to step 200 to obtain the loads L(i,j). Those of 

25 ordinary skill will recognize that the loads L(i,j) may 
change during the reporting interval as various sub- 
tasks within the processes are completed or become ac- 
tive or inactive. In the event that the reporting interval 
has expired, the LBR process continues to step 212, 

30 where aggregate load values are determined for each 
sub-task priority level. At step 21 2, LBR 1 20 aggregates 
the load L(i.j) for each priority level (j). The aggregate 
toad attributable to a given sub-task priority level (j) may 
be expressed as: 

35 

AGG(j)=L(1,j) + L(2,j)+...L(n,j) (1) 

where n is the number of processes. 

*o [0019] At step 214, the LBR process determines the 
aggregate load distribution or target ratios. These rep- 
resent the ratio of the aggregate highest priority sub- 
task load to each of the aggregate lower priority loads. 
At step 21 6, the aggregate load ratios are reported to 

45 the reporting sub-task of each process for use by the 
corresponding scheduler in a manner explained below. 
[0020] Figure 2 represents the generalized logic flow 
of the LBR process. An example of the generalized logic 
flow applied to a simplified system involving only three 

so processes and only two sub-task priority levels is in- 
structive with regard to the LBR process. Such an ex- 
ample wilt be explained with reference to Figures 4A, 
which represents the CPU load distribution during the 
initial LBR reporting interval for such a simplified sys- 

s$ tern. Step 200 would involve the determination six CPU 
loads L(i,j) - two for each of processes 1 , 2 and 3. Thus, 
at the initial reporting interval, the 100 milliseconds jr/s) 
load, which is the time interval allotted by the operating 
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system, attributable to process 1 is comprised of 20 ms 
attributable lo high priority (priority level 1) sub-tasks, 
while 80 ms is attributable to lower priority sub-tasks 
(prfotity level 2). The loads for processes 2 and 3 are 
similarly represented in Figure 4A. The total CPU load 
is 100 ms for each process because the operating sys- 
tem allots a time slice of 100 ms to each process. While 
each process can relinquish control to the operating sys- 
tem before the time slice expires, processes cannot in- 
crease the time slice beyond the interval allotted by the 
operating system. Since this example concerns the first 
LBR reporting interval, step 210 would, by definition, 
branch to step 212 where two aggregate loads AGG(1 ) 
and AGG(2)-- one for each sub-task priority level are 
determined. In this example, the valuetor AGG(1 ) would 
be 150 ms and the value for AGG(2) would be 1 50 ms. 
At step 214, one aggregate ratio would be determined: 
AGG{1):AGG(2) which is equal to 120:180. The aggre- 
gate load ratio in this case thus represents that on av- 
erage with regard to all active processes (in this case 
three), more CPU load is attributable to low priority sub- 
tasks than is attributable to high priority sub-tasks. 
[0021] Figure 3 is a flow chart representing the logic 
flow in a process scheduler 126. At step 300 scheduler 
1 26 obtains the aggregate load distribution or target ra- 
tio^) from the LBR. Next, at step 310, all highest priority 
(i.e., priority level 1 ) sub-tasks that are ready are sched- 
uled and executed by the CPU. The scheduling process 
then proceeds to step 320 where the next lower priority 
sub-tasks are scheduled and executed. At step 330. the 
process determines whether new higher priority sub- 
tasks have become active. If so, these sub-tasks are 
scheduled and executed as the process branches back 
to step 310. If no new higher priority sub-tasks have be- 
come active, the process determines the current load 
distribution at 340. Step 345 involves a determination 
as to whether the CPU time slice allocated to the proc- 
ess has expired. If so, the routine branches to step 360 
where process control is relinquished to the operating 
system. 1f the CPU time slice has not expired, the proc- 
ess continues to step 350. At step 350, the scheduler 
determines whether the current load distribution ratio is 
lower than the aggregate load distribution ratio, the 
process branches back to step 320 where the allotted 
CPU resources are applied to lower priority sub-tasks. 
If the current toad distribution ratio is not less than the 
aggregate load distribution ratio, the process proceeds 
to step 360 where the load attributable to the process is 
adjusted by reducing the time allotment provided to that 
process. 

[0022] Those of ordinary skill in the art will recognize 
that the logic flow depicted in Figure 3 is applicable to 
systems having two or more sub-task priority levels. In 
the case of three sub-task priority levels, for example, 
the scheduling process would first adjust CPU load 
based on current toad distribution represented by the 
highest and second-highest priority levels. If all sub- 
tasks of highest and second-highest priority levels are 



completed, the process would then determine the dis- 
tribution ratio at step 350 by evaluating the CPU load 
attributable to the third-highest priority level and adjust- 
ing the load when the load distribution respecting the 
5 highest and third-highest priority levels reach the aggre- 
gate values. 

[0023] Returning to the simplified example discussed 
above with respect to Figure 4A, The load distribution 
during the second LBR reporting interval is shown in the 

10 table in Figure 4B. The CPU load distribution will be ad- 
justed during the second LBR reporting interval as a re- 
sult of the schedulers 126 of processes 1 and 2. This 
distribution represents a simplified situation in which no 
new high priority sub-tasks become active during the 
second reporting interval. Typically, however, new high 
priority sub-tasks will become active and the load distri- 
bution within the process will be altered. Importantly, the 
scheduler 1 26 in process 1 voluntarily relinquishes CPU 
resources after 50 ms because process 1 will meet the 

20 target distribution ratio, 1 20: 180 after 20 milliseconds of 
high priority work and 30 seconds of low priority work 
are performed. The load distribution of process 2 re- 
mains unaltered because its original distribution is equal 
to the target distribution ratio. Process 3 will perform 60 

2S ms of high priority work and 40 ms of low priority work, 
as in the initial LBR reporting interval. Although process 
3 would need to perform 90 ms of low -priority work to 
meet the target distribution ratio, only 100 ms of time is 
allotted by the operating system. 

30 [0024] It will be recognized that during the second 
LBR reporting interval, the CPU load attributable to 
process 1 has been reduced from 100ms to 50 ms. 
Therefore, CPU resources will be applied to processes 
2 and 3 50 ms earlier than would be the case without 

35 LBR implementation. Thus, high-priority sub-tasks with- 
in process 3 will be addressed earlier because of the 
LBR implementation. This results a more frequent ap- 
plication of CPU resources to processes that are busy 
with a relatively large proportion of high priority sub- 

40 tasks. 

[0025] Further iterations of the third and fourth LBR 
reporting intervals in the three -process, two-priority lev- 
el example are shown in Figure 4C and Figure 4D, re- 
spectively. Referring to Figure 4C, the CPU resources 
applied to process 1 is further reduced to 41 .6 ms. Sim- 
ilarly, the CPU resources applied to process 2 are re- 
duced from 100 ms (Figure 4B) to 83.2 ms. Process 3, 
which has the highest load distribution ration (60:40) will 
receive processing time after (42 +83 =) 125 ms, or 
50 about 25 ms earlier than in the previous iteration repre- 
sented by Figure 4B. Referring to Figure 4D : CPU re- 
sources are applied to process 3 after (38 + 75 = ) 1 1 3 
ms. It will be recognized that further iterations of the LBR 
will result in further reduction in the aggregate load dis- 
ss tribution ratio and each application process will drift to- 
ward equal load distributions. 

[0026] The present invention thus provides for a shift 
of CPU resources away from processes that are occu- 
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pied with a relatively low proportion of high priority sub- 
tasks towards application processes that are occupied 
with relatively high proportion of high-priority sub-tasks. 
It is to be understood that the preceding description re- 
lates to only one preferred embodiment of the invention. 
Numerous other arrangements and modifications will 
occur to those of ordinary skill upon a reading of this 
specification. The scope of the invention is intended to 
cover all such arrangements and modifications and will 
be defined in the accompanying claims. 



of the selected process; and 

iii) relinquishing a portion of the CPU resources 
allotted to the selected process by the operat- 
ing system when the current load distribution 
ratio of the selected process equals or exceeds 
the aggregate load distribution ratio. 

5. The method according to claim 1 , wherein the step 
of determining a load distribution ratio comprises 
the steps of: 



Claims 

1. In a digital processing system having a central 
processing unit (CPU) and an operating system for 
executing a plurality of active application process- 
es, the operating system allotting CPU resources to 
each process, each process including a plurality of 
sub-tasks, each sub-task being assigned one of a 
plurality of priority levels, the priority levels including 
a highest priority level and at least one lower priority 
level, a method of balancing the CPU load compris- 
ing the steps of: 

a) determining a load distribution ratio for each 
process the load distribution ratio representing 
the ratio of CPU resources allotted to highest 
priority sub-tasks to CPU resources allotted to 
each level of lower priority sub-tasks within the 
process; 

b) determining an aggregate load distribution 
ratio representing the ratio of total CPU re- 
sources allotted to highest priority sub-tasks to 
total CPU resources allotted to each level of 
lower priority sub-tasks among the processes; 
and 

c) adjusting the CPU resources applied to a se- 
lected process when the load distribution ratio 
of the selected process differs from the aggre- 
gate load distribution ratio. 

2. The method according to claim 1 , wherein the step 
of adjusting comprises the step of limiting CPU re- 
sources applied to the selected process. 

3. The method according to claim 1 , wherein the sub- 
tasks are assigned one of two priority levels. 

4. The method according to claim 1 , wherein the step 
of adjusting further comprises the steps of: 

i) reporting the aggregate load distribution ratio 
to the selected process; 

ii) determining a current load distribution ratio 



i) determining the amount of CPU time occu- 
pied by highest priority sub-tasks; and 

ii) determining the amount of CPU time occu- 
pied by each level of lower priority sub-tasks. 

6. In a digital processing system having at least one 
central processing unit (CPU) for executing a plu- 
rality of processes, each process including a plural- 
ity of sub-tasks, a method of balancing load on the 
at least one CPU comprising the steps of: 

a) assigning either a high or low priority level to 
each of the sub-tasks; 

b) determining a load distribution ratio lor each 
process, the load distribution ratio being de- 
fined as the ratio of the load attributable to high 
priority tasks to the load attributable to low pri- 
ority tasks; 

c) determining an aggregate load distribution 
ratio by aggregating the load distributions ratios 
for each process; 

d) adjusting the load attributable to at least one 
selected process when the load distributbn ra- 
tio of the selected process differs from the ag- 
gregate load distribution ratio. 

1. The method according to claim 6, wherein the step 
of adjusting comprises the step of limiting CPU re- 
sources applied to the selected process. 

8. The method according to claim 6, wherein the step 
of adjusting further comprises the steps of: 

reporting the aggregate load distribution ratio 
to the selected process; 

determining a current load distribution ratio of 
the selected process; and 

relinquishing a portion of the CPU resources al- 
lotted to the selected process by an operating 
system when the current load distribution ratio 
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of the selected process equals or exceeds the 
aggregate load distribution ratio. 

9. ¥ the method according to claim 6, wherein the step 

of determining a load distribution ratio comprises 
the steps of: 

determining the amount of CPU time occupied 
by highest priority sub-tasks; and 

determining the amount of CPU time occupied 
by each level of lower priority sub-tasks. 

10. In a time-sharing digital processing system having 
a central processing unit for executing a plurality of 
non-communicating processes stored in memory, 
each process including a plurality of sub-tasks, a 
method of load balancing comprising the steps of: 

a) assigning one of a plurality of priority levels 
to each sub-task, the priority levels including a 
highest priority level and at least one lower pri- 
ority level; 

b) periodically determining a target load distri- 
bution ratio based on the ratio of the aggregate 
CPU resources attributable to highest priority 
sub-tasks to the aggregate CPU load among 
the processes attributable to each level of lower 
priority sub-tasks; 

c) limiting the load attributable at least one se- 
lected process when the load distribution ratio 
of the at least one selected process equals the 
target load distribution. 

11. The method according to claim 1 0, wherein the step 
of limiting comprises the step of relinquishing a por- 
tion of a time slice of the central processing unit to 
an dbe rating system. 

1 2. The method according to claim 1 0, wherein the step 
of assigning further comprises the step of assigning 
one of two priority levels. 

1 3. The method according to claim 1 0, wherein the step 
of limiting further comprises the steps of: 



get load distribution ratio. 

14. The method according to claim 1 0, wherein the step 
of determining a load distribution ratio comprises 

5 the steps of: 

i) determining the amount of CPU time occu- 
pied by highest priority sub-tasks; and 

io ii) determining the amount of CPU time occu- 

pied by each level of lower priority sub-tasks. 

15. In a digital processing system, including a central 
processing unit for executing a plurality of applica- 

is tion processes, memory for storing instructions cor- 
responding to the application processes, each of 
the processes including a plurality of sub-tasks, 
each having either a high or low priority level as- 
signed thereto, a system for distributing load on the 

20 central processing unit comprising: 

a) a scheduler associated with each of the proc- 
esses for scheduling the execution of sub-tasks 
within a corresponding process, each schedul- 
es er determining the load distribution among h igh 

and low priority sub-tasks within that process; 

b) a load balance repository for receiving the 
load distribution from each process and for de- 

30 termining a target load distribution; and 

c) each scheduler limiting the load attributable 
to a corresponding process when the toad dis- 
tribution of the corresponding process differs 

3S trom the target load distribution. 

16. The system according to claim 1 5, wherein the load 
balance repository determines the target load dis- 
tribution based on the ratio of the aggregate central 

40 processing unit load attributable to high priority sub- 
tasks to the aggregate central processing unit load 
attributable low priority sub-tasks. 

17. The system according to claim 15, wherein each 
4£ scheduler is provided with a reporting sub-task for 

reporting a corresponding load distribution to the 
load balance repository. 



40 



AS 



2S 



i) reporting the target load distribution ratio to 

the selected process; so 

ii) determining a current load distribution ratio 
of the selected process; and 

iii) relinquishing a portion of the CPU time allot- ss 
ted to the selected process by an operating sys- 
tem when the current load distribution ratio of 

the selected process equals or exceeds the tar- 



18. The system according to claim 15, wherein each 
scheduler is adapted to relinquish a portion of a time 
slice allotted to the corresponding process by an op- 
erating system when the toad distribution in the cor- 
responding process equals or exceeds the target 
load distribution. 
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